September 22, 1991 By Mike Bilow, N1BEE AX.25: N1BEE @ KA1RCI.RI.USA.NA Internet: mikebw@idsvax.ids.com Amprnet: n1bee@n1bee.ampr.org [44.104.0.20] Fidonet: MIKE BILOW, 1:323/120 Standard post: Forty Plantations, Cranston, RI 02920-5554, USA For GRINOS/GRINOS-S KA9Q 910618/PA0GRI 910822v1.7h/N1BEE 910921v0.72 All users of GRINOS/GRINOS-S are invited to join the grinos@n1bee mailing list. This is what I use to distribute advisories and updates. There is no requirement that you actually use GRINOS in order to join the mailing list. Just send a message to me and you will be added. Users accessible to me via the Amprnet will receive their updates that way, and others via the conventional packet BBS forwarding system. I. KA9Q/PA0GRI changes Despite the new feature added by PA0GRI which allows selecting not to include the AXIP (Internet wormhole AX.25 encapsulation) code at compile time, actually taking the code out causes NOS to fail to recognize IP frames for itself, although they trace perfectly. This is a fairly serious bug somewhere, but the AXIP code remains in the N1BEE executables just to keep them working. II. N1BEE changes A. TCP backoff limit (as of N1BEE 910903v0.70-alpha test) After much controversy, I have made major changes to the backoff clamp that first appeared several versions ago. Most importantly, the command name has been changed to "tcp bblimit" instead of the old "tcp blimit". This is to avoid confusion with a similarly named but functionally different command that is in wide use with the releases of G1EMM code from Brian Ellsworth, KA1JY. In addition, this new clamp command has a minimum value of 10. This is not to imply that such a low minimum value is appropriate when using the linear backoff algorithm, but rather to prevent users from accidentally setting the clamp to grossly inappropriate values. The default of 31 is probably a good choice; 31 was also the maximum in previous versions, but now the clamp can be set as high as 32767 (which is tantamount to disabling it). The new "tcp bblimit" command can also be used to clamp exponential backoffs now, although it will be rtt dependent and therefore different for each channel. When used for exponential backoff, tcp bblimit values greater than 31 will be ignored, and a clamp of 31 imposed; this is a restriction of the original NOS code, and is not under my control. B. Domain name translation (as of N1BEE 910805v0.61-alpha test) In order to facilitate better handling of RSPF, although not in any way specific to it, translation of IP addresses to domain name is now inhibited for all addresses with a last octet of 0 or 255. This usually affects only screen displays of routing tables and the like. However, traces of RSPF update frames, which would frequently include addresses of this form, would hang NOS while attempting to translate these bogus addresses into domain names by searching the DOMAIN.TXT file. Although these hangs were temporary, they were very annoying, and are eliminated. The applies, of course, only when "domain translate" has been turned on. C. ARP bug fix (as of N1BEE 910919v0.71-beta test) ARP requests generated by other hosts but seen by GRINOS which claimed to be from [0.0.0.0] and seeking [0.0.0.0] would crash GRINOS, even though GRINOS was doing nothing other than monitoring them. All ARP processing is now prevented on such frames, which are intercepted and discarded if either sender or target address is [0.0.0.0]. D. RSPF bug fix (as of N1BEE 910919v0.71-beta test) The very frustrating RSPF bug that caused routes to go "tentative" forever seems to have been repaired. This was in connection with the record keeping related to the ping processes started by RSPF. An added line is provided (probably on a temporary basis) in the display from "rspf status" in order to show the counts for Nrspfproc and Keeprouter. While occasional excursions from zero are normal, these counters should return to zero after excursions and should nearly always display as zero. Persistent non-zero values for these counters, RSPF routes going permanently tentative, and so forth, should be reported. In addition, Walt, KZ1F, has been making significant progress on cleaning up some of the dirty pointer code in RSPF. This should also add to the stability of NOS as a whole. While the Rhode Island LAN has been running what I call "The World's Largest RSPF Net," it should be understood that the feature is experimental. Anyone wishing to do their own experiments, with the permission of their local switch administrator, is encouraged to contact me for more information. It should be understood that fairly drastic consequences for an entire RSPF network can easily ensue from just one RSPF host that is set up incorrectly. E. Ottowa PI driver now standard (as of N1BEE 910921v0.72) Due to some demand by the group in Dayton, Ohio, I have made the Ottowa PI driver a standard feature of the large version of GRINOS. The small version will not be affected. Since I have no hardware on which to test the driver, I am running pretty much blind. Inquiries can be directed to the Dayton group liaison by Internet to address or by AX.25 to AG9V @ N8ACV.OH.USA.NA. He may not be able to help you, but he cannot possibly know any less than I do about it, and he will be in a better position to commiserate with you. F. NNTP client support withdrawn (as of N1BEE 910921v0.72) The inclusion of the Ottowa PI driver meant that something had to go, preferably something large. Although I had hopes of encouraging some experimentation with NNTP via Amprnet, I know of no one actually using NNTP with my executables. In order to keep the memory requirements at a reasonable level, in addition to the need to be able to link successfully into a DOS executable with a 64K near data segment, support for NNTP is now ended. The small version of GRINOS is again unaffected, as the NNTP client support was never in it. G. Compression method changed (as of N1BEE 910921v0.72) Previous releases of GRINOS executables have been compressed with PKLITE v1.12 after preprocessing with HDROPT v1.12 per the documentation from PKware. Serious problems have been observed with several versions, which I believe are related to bugs in HDROPT. For example, this release of GRINOS-S.EXE will crash immediately on my machine (a 386 running QEMM) with a general protection fault if HDROPT is used, but appears to work correctly otherwise. Therefore, use of HDROPT will be discontinued. The resulting files will be slightly larger on disk as a result, but will not occupy a different amount of space once loaded into memory. III. Documentation A. From PA0GRI I have a copy of Gerard's original documentation for his v1.7h, which is the basis for my v0.7x series. I am in the process of editing it and trying to correct any inconsistencies produced by my customizations. When it is available, I will announce that fact and post it in the usual places. B. Sample AUTOEXEC.NOS In response to numerous requests, I am binding a sample AUTOEXEC.NOS into the distribution ZIP files. Almost no one will be able to use it as is, but it should provide some general hints and a place to start. I am going to write it as if the user was taking part in our POP system at switch.w1cg-9.ampr.org [44.104.0.2], and in our RSPF experiment so that users can see how that is done here. As explained, the RSPF system should not be used except as part of an organized test, and POP requires making arrangements with the postmaster of some POP server. I am a believer in very short and simple AUTOEXEC.NOS files. IV. Support and distribution The ChowdaNet BBS has now joined Fidonet with address 1:323/120, but file requests are not supported at this time. In order to operate with the network front-end software, we have switched the modems. Callers wishing to restrict their connection to 9600 baud using V.32/V.42bis should now call (401)331-0907. Callers wishing to permit any speed connection should call (401)331-0334, which will automatically hunt to the other line if busy. The 0334 line is at this time answered by a Telebit Trailblazer modem, which will allow 19200 baud PEP with another PEP-compatible modem, but only 2400 baud MNP5/V.42 for regular modems. ChowdaNet remains the official landline central distribution point for all GRINOS executables and source. Executables only are posted for FTP on the Amprnet at New England sites wb6nil.ampr.org [44.56.0.64] and switch.w1cg-9.ampr.org [44.104.0.2]. These are what I guarantee to be current, although posts may have been made to other sites.